System and method for content streaming with feature detection

ABSTRACT

A system and method for content streaming with feature detection, comprising determining a streaming format compatibility criteria of a remote web browser, determining a content selection from a list of one or more content selections, receiving at a content server a streaming request, streaming the content selection, the streaming including dividing a source content into a plurality of segment files, encrypting the plurality of segment files, sending a manifest file from the content server to the remote web browser, receiving requests at the content server for each of the plurality of segment files and a decryption key, sending from the content server each one of the requested plurality of segment files and the decryption key, and selecting the next content selection in the list until the last content selection is selected and streamed.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/048,566, filed Feb. 19, 2016, entitled SYSTEM AND METHOD FOR CONTENTSTREAMING WITH FEATURE DETECTION (Atty. Dkt. No. VLGP-32918), which is acontinuation of U.S. patent application Ser. No. 14/749,929, filed Jun.25, 2015, now U.S. Pat. No. 9,270,724, issued on Feb. 23, 2016, andentitled SYSTEM AND METHOD FOR CONTENT STREAMING WITH FEATURE DETECTION(Atty. Dkt. No. VLGP-32622).

TECHNICAL FIELD

The following disclosure related to digital content streaming and, morespecifically, to HTTP Live Streaming (HLS) of digital content.

BACKGROUND

Streaming digital content over the Internet has developed into one ofthe most preferred and effective ways of delivering digital content toaudiences around the globe. However, various difficulties arise indelivering content to multiple platforms, each platform potentiallyhaving different browsers and different versions of those browsers.Compatibility issues thus arise and streaming content providers have toprovide some way to deliver content to as many users as possible in asecure fashion. One of the most popular streaming formats is Flashstreaming. In most cases, Flash is available on personal computers, butnot available for mobile devices.

HTTP Live Streaming is a streaming format originally designed for use instreaming video content. As a result, HTTP Live Streaming does notaccount for separate items of content to be consumed in sequence, suchas in a playlist. Therefore, in order to accommodate playlists, othermeasures must be implemented.

SUMMARY

In one aspect thereof, a system and method for content streaming withfeature detection is provided. The system and method comprises storing asource content to be streamed on a content server disposed on a network,determining a streaming format compatibility criteria of a remote webbrowser to determine if the remote web browser is HTTP Live Streamingcompatible, and, if so, selecting by a content presentation interfacedisposed in a webpage loaded in the remote web browser a contentselection from a list within the webpage of one or more contentselections, each content selection including an identification ofcontent, a location of the content server, and an access token,receiving at the content server a HTTP Live Streaming request from theremote web browser for the content selection, the request including theidentification of the content and the location of the content server,streaming the content selection from the content server to the remoteweb browser via the network. The streaming includes dividing the sourcecontent into a plurality of segment files, encrypting the plurality ofsegment files, sending a manifest file from the content server to theremote web browser containing links to provide access to the pluralityof segment files and to a decryption key associated with the pluralityof segment files, receiving requests at the content server from theremote web browser for each of the plurality of segment files and forthe decryption key from the remote web browser; and sending from thecontent server to the remote web browser each one of the requestedplurality of segment files and the requested decryption key, to be usedto decrypt each of the plurality of segment files, as each request foreach of the plurality of segment files is received, and repeating thestreaming steps, while playback is performed until the last contentselection is selected and streamed, in order to buffer additionalcontent to allow for continuous playback of the list of one or morecontent selections.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding, reference is now made to thefollowing description taken in conjunction with the accompanyingDrawings in which:

FIG. 1 illustrates a diagrammatic representation of a digital contentstreaming network;

FIG. 2 illustrates a flow diagram of one embodiment of a customerwebpage development process;

FIG. 3A illustrates a flow diagram of one embodiment of a custodiancontent streaming process;

FIG. 3B illustrates a continuation of the flow diagram of FIG. 3A;

FIG. 4 illustrates a flow diagram of one embodiment of a CDN providerstreaming process;

FIG. 5A illustrates a flow diagram of one embodiment of an end userstreaming process;

FIG. 5B illustrates a continuation of the flow diagram of FIG. 5A;

FIG. 6A illustrates a diagrammatic representation of one embodiment of aHLS streaming process; and

FIG. 6B illustrates a continuation of the diagrammatic representation ofthe embodiment of the HLS streaming process of FIG. 6A.

DETAILED DESCRIPTION

Referring now to the drawings, wherein like reference numbers are usedherein to designate like elements throughout, the various views andembodiments of a system and method for content streaming with featuredetection are illustrated and described, and other possible embodimentsare described. The figures are not necessarily drawn to scale, and insome instances the drawings have been exaggerated and/or simplified inplaces for illustrative purposes only. One of ordinary skill in the artwill appreciate the many possible applications and variations based onthe following examples of possible embodiments.

Referring now to FIG. 1, there is illustrated a diagrammaticrepresentation of a digital content streaming network 100. The network100 includes an IP network 102 to accommodate communication between thevarious nodes in the network 100. The network 100 further includes acustodian server 104, which includes a custodian database 106,maintained by a custodian 103. The custodian database 106 may containvarious database records 108 that include identifying informationrelating to potential streaming content, as well as copies of accesstokens that may be used to authenticate access to said streamingcontent. The network 100 also includes a custodian HTTP Live Streaming(HLS) server 110, also maintained by the custodian 103, to facilitateHLS streaming of digital content. The network 100 may also include aContent Delivery Network (CDN) provider server(s) 112 having contentstorage 114. The CDN provider server(s) 112 may be maintained by athird-party having an agreement with the custodian 103 to provideservers for storage and streaming of content on behalf of the custodian103. This type of arrangement is beneficial to the custodian 103 as itallows the custodian 103 to avoid performing all storage of content andall streaming services at the custodian server 104 or the custodian HLSserver 110, as well as providing established and reliable servers forthose wishing to use the custodian's streaming services.

It will be appreciated by those skilled in the art that the CDN providerserver(s) 112 are not necessary for storage and streaming of content, asthe custodian server 104 or the custodian HLS server 110 could be usedinstead, but merely provide convenience and more affordability to thecustodian 103. The network 100 also may include a customer 116 having acustomer webpage 118. The customer would typically be a customer of thecustodian 103. In this type of arrangement, the custodian 103 wouldallow streaming content to be accessed by way of an end user 120accessing the customer webpage 118 via an end user browser 122. The enduser browser 122 is a web browser, such as Internet Explorer, Safari,Firefox, Google Chrome, or another browser. The customer 116 would beprovided with access tokens associated with specific content stored onthe custodian server 104, the custodian HLS server 110, or the CDNprovider server 112. The database records 108 contain copies of theaccess tokens in relation to content information also stored in thedatabase records 108. The access tokens allow one to access streamingcontent when provided to the custodian server 104. The customer webpage118 has web scripting written in a scripting language, such as Perl,Python, or JavaScript, for example, to check the streaming formatsupported by the end user browser 122, as well as to provide the accesstokens to the end user browser 122. Additionally, the customer webpage118 will typically contain an interface for presenting streaming contentto the end user 120.

Still referring to FIG. 1, the end user 120 utilizes the end userbrowser 122 to access the customer webpage 118. The customer webpage 118may be generated and served to the end user browser 122 by a web server,by the customer 116, or another third party provider. Once the customerwebpage 118 is loaded in the end user browser 122, all subsequentcommunications to facilitate streaming no longer require participationfrom the customer 116. The customer webpage 118 loaded in the end userbrowser 122 will determine whether the end user browser supportsavailable streaming formats, such as Flash, HLS, MPEG-Dash, or otherstreaming formats. The customer webpage 118 will also provide accesstokens to the end user browser 122. The end user browser 118 thencontacts the custodian server 104 to start the streaming process.Throughout the streaming process, the end user browser 122 maycommunicate with the custodian HLS server 110, the CDN provider server112, or both, in addition to the custodian server 104.

Referring now to FIG. 2, there is illustrated a flow diagram of oneembodiment of a customer webpage development process 200. At step 202,the customer 116 requests an arrangement for a content streaming serviceto be implemented by custodian 103. At step 204, the customer 116receives access tokens associated with the specific content from thecustodian 103. The access tokens preferably have a set duration of timebefore they expire, in order to provide that the custodian 103 is notstreaming content after an agreement with a customer has reached itstermination date. Further, one access token may provide access tomultiple pieces of content to be streamed, or multiple access tokens maybe provided that are each associated with a single piece of content. Atstep 206, the customer 116 establishes the customer webpage 118 whereinthe customer webpage 118 includes feature detection and token accessscripts, as well as a content presentation interface, such as an audioplayer, for example. The content presentation interface would beconstructed using available web design methods, such as beingconstructed using HTML. At step 208, the customer webpage 118 receives arequest from the end user browser 122 to access the customer webpage208. At step 210, the end user browser 122 accesses the customer webpage118. It will be appreciated by one skilled in the art that other meansof streaming content may be provided, even without requiring a customer116. For instance, the custodian 103 may produce its own website havinga content presentation interface, or it may provide a contentpresentation interface in some other format, such as in an email. Theemail would then be sent to certain recipients and would stream contentonce opened through the content presentation interface. The customer 116may also choose to use the email method to reach the end user 120,rather than through the customer webpage 118. These methods of providinga content presentation interface allows the customer 116 to provide forcontent to be streamed in a secure and encrypted manner through thecustomer webpage 208, or other means, without the need of developing aPC or mobile application to provide the content to the user. This iscritical because a content provider licensing their content forstreaming purposes typically desires that content be streamed in asecure and encrypted manner, which HLS streaming provides, as describedhereinbelow. Thus, the customer 116 saves on the cost of developing astand-alone application, while the content provider's desire thatcontent be streamed in a secure and encrypted manner is fulfilled.

In addition to utilizing email to reach the end user 120, the customer116 may also use social media applications, as well. For example, thecontent presentation interface may be embedded in a social mediaprocess, such as a posting by a user on a social media website. Theposting would include the content presentation interface, and others whoview the post would be able to interact with the content presentationinterface in order to stream content. It will be appreciated by oneskilled in the art that the content presentation interface may be usedin various media and in various formats, without being restricted to theexample provided herein.

Referring now to FIGS. 3A and 3B, there is illustrated a flow diagram ofone embodiment of a custodian content streaming process 300. At step302, the custodian 103 receives source content from a content provider.Typically, the source content is in a digital format, such as MP3 files.The content provider may provide a catalog of content to the custodian103, or individual pieces of content. The content provided may bevarious types of content, such as audio content, video content, or otherforms of content for streaming. At step 304, the database records 108 ofthe custodian database 106 are updated with information related to thecontent provided by the content provider, such as the title, length, andother identifying information. At step 306, the custodian 103 stores thecontent provided by the content provider on the CDN provider server(s)112. Preferably, the custodian 103 does not have to permanently storeany content on either the custodian server 104 or the custodian HLSserver 110, although content may be stored on the custodian server 104or the custodian HLS server 110 without departing from the presentinventive concept. At step 308, the custodian 103 generates accesstokens and stores the access tokens in the custodian database 106 inassociation with particular content to be streamed. At step 310, thecustodian 103 provides the access tokens to the customer 116 in order toprovide access to content to be streamed to the end user 122 visitingthe customer webpage 118. At step 312, the custodian server 104 receivesa request from the end user browser 122 containing the access token andthe streaming format capability as determined by the customer webpage118. At step 314, the custodian server 104 checks the access tokenreceived from the end user browser 122 against the access token storedin the custodian database 106. At step 316, if the access token isdeemed valid, that is, if the access token matches an access tokenstored in the custodian database 106 and the access token has notexpired, the process moves on to step 320. If the access token is deemedinvalid, the process moves to step 318. At step 318, the custodianserver 104 sends a message to the end user browser 122 stating that theaccess token is not valid, or some other applicable message.

If the token is valid, at step 320, the streaming format compatibilitythat was received by the custodian server 104 is checked. If HLSstreaming was not requested, but some other streaming format wasrequested, such as Flash, or another streaming format, the process maymove to step 322 where the custodian server 104 redirects the end userbrowser 122 to the CDN provider server(s) 112 in order for the CDNprovider server(s) 112 to facilitate the rest of the streaming process.It will be appreciated by one skilled in the art that the custodian 103could provide the streaming of the Flash content, if the custodian 103so desired. Streaming formats other than Flash, such as MPEG-Dash, mayadvance the process to step 322, to allow the CDN server(s) 112 tofacilitate the rest of the streaming process, or the process maycontinue to step 324. If it is determined that HLS streaming isrequested, the process moves to step 324. It will be appreciated thatother streaming formats, such as MPEG-Dash, may also cause the processto move to step 324, and thus follow the same process as an HLSstreaming request, instead of advancing to step 322. At step 324, theend user browser 122 is redirected to the custodian HLS server 110. Atstep 326, the custodian HLS server checks the current status of thecontent to be streamed. At step 328, it is determined if the requestedcontent is already segmented and encrypted, and, thus, is already readyto be streamed to the end user browser 122. If the requested content isalready segmented and encrypted, the process moves to step 330 where thecustodian HLS server 110 sends a manifest file, also known as an indexfile, to the end user browser 122 containing the links to the segmentfiles which are stored on the CDN provider server(s) 112. The CDNprovider server(s) 112 would handle the streaming process from thatpoint. If, at step 328, it is determined that the content is not alreadysegmented and encrypted, the process moves to step 332.

At step 332, the custodian HLS server 110 downloads the source file ofthe requested content from the CDN provider server(s) 112. At step 334,the custodian HLS server 110 divides the downloaded file into segmentfiles. The file would be divided into segment files containing contentof equal length, such as 10 second segments. At step 336, the custodianHLS server encrypts the segment files via OpenSSL, or some othercryptology library. At step 338, the custodian server 110 sends amanifest file to the end user browser 122 containing links to thesegment files currently stored on the custodian HLS server 110. Themanifest file also contains a link to a decryption key, and informationconcerning each segment file, such as the length, in seconds, of thesegment file. At step 339, the custodian HLS server 110 receives arequest for the decryption key. At step 340, the custodian HLS server110 sends the requested decryption key to the end user browser 122. Atstep 341, the custodian HLS server 110 receives a request for a segmentby the end user browser 122 by activating the link to that segment inthe manifest file. At step 342, the custodian HLS server 110 sends therequested segment file to the end user browser 122. At step 344, it isdetermined whether the segment sent in step 342 was the final segment inthe manifest file, if it was not the process moves back to step 340 inorder to send the next segment. If it was the final segment in themanifest file, the process moves to step 346. At step 346, the segmentedfiles produced in step 334 are uploaded to the CDN provider server(s)112. This allows the CDN provider server(s) 112 to handle subsequentrequests for this same piece of content. Essentially, this enable to thecustodian HLS server 110 to only have to cut and stream HLS content whena piece of content has not yet been segmented.

Referring now to FIG. 4, there is illustrated a flow diagram of oneembodiment of a CDN provider streaming process 400. At step 402, the CDNprovider server(s) 112 receives content form the custodian 103. Thiscontent may be source content received from the custodian 103's contentprovider, or it may be newly segmented content ready to be streaming viaHLS streaming. At step 404, the CDN provider server(s) 112 receives astream request from the end user browser 122. The CDN provider server(s)112 then determines whether HLS or some other form of streaming isrequested, such as Flash. If HLS is not requested, then, at step 408,the CDN provider server(s) 112 streams the non-HLS content according toa non-HLS streaming protocol, such as Flash streaming. If, at step 406,it was determined that HLS streaming is requested, the process moves tostep 416. At step 416, the CDN provider server(s) 112 sends a manifestfile to the end user browser 122 containing links to segment files and adecryption key stored on the CDN provider server(s) 112. At step 417,the CDN provider server(s) 112 receives a request for the decryption keyvia the link contained in the manifest file. At step 418, the CDNprovider server(s) 112 sends the requested decryption key to the enduser browser 122. At step 419, the CDN provider server(s) 112 receives arequest from the end user browser 122 for a segment file via the linkcontained in the manifest file. At step 420, the CDN provider server(s)112 sends the requested segment file to the end user browser 122. Atstep 422, it is determined whether the segment file sent in step 420 wasthe last segment in the manifest file. If it was not the last segment,the process loops back to step 418 to receive a request for the nextsegment file. If it was the last segment file, the process ends at step424.

Referring now to FIGS. 5A and 5B, there is illustrated a flow diagram ofone embodiment of an end user streaming process 500. At step 502, theend user 120 opens the end user browser 122. At step 504, the end user120 navigates to the customer webpage 118 using the end user browser122. At step 506, the end user browser 122 loads the customer webpage118, the customer webpage 118 containing feature detection and accesstoken scripts. At step 508, the feature detection script determines ifthe end user browser 122 is compatible with Flash streaming. The featuredetection scripts are typically written by the custodian 103 andprovided to the customer 116 as part of the content presentationinterface. The feature detection scripts determine if the end userbrowser 122 is compatible with available streaming options. For example,if the end user browser 122 is being run on a personal computer (PC),rather than a mobile device, the browser likely supports Flashstreaming. The feature detection scripts would detect this compatibilityand move forward in the process. On the other hand, if the end userbrowser 122 is running on a mobile device, or, for some reason, the PCbrowser is not compatible with Flash streaming, the script willdetermine if HLS can be used. Thus, feature detection is an importanttool for allowing content to be streamed over a wide variety ofplatforms and browsers.

If the end user browser 122 is compatible with Flash streaming, theprocess moves on to step 514. If the end user browser 122 is notcompatible with Flash streaming, the process moves to step 510, wherethe feature detection script determines if the end user browser iscompatible with HLS streaming. If the end user browser is compatiblewith HLS streaming, the process moves on to step 514. If the end userbrowser 122 is not compatible with HLS streaming, an error message isdisplayed in the end user browser 122. At step 514, a contentpresentation interface, such as an audio player, is displayed to the enduser. At step 516, the end user 120 selects content and initiates astream request by interacting with the content presentation interface.This may simply include the end user 120 pressing a “play” button. Thecontent presentation interface may also start automatically after thecustomer webpage 118 is loaded in the end user browser 122 and theappropriate checks in steps 508 and 510 are performed.

At step 518, a stream request including the access token and streamingformat compatibility is sent from the end user browser 122 to thecustodian server 104. At step 520, if the custodian server 104determines the access token is invalid, then at step 522 the end userbrowser 122 receives an error message. If the custodian server 104determines the access token is valid, the process moves to step 524. Atstep 524, the custodian server 104 reacts to the streaming formatcompatibility of the end user browser 122. If the end user browser 122is requesting Flash content, for example, then at step 526 the end userbrowser is redirected to the CDN provider server(s) 112. At step 526,the end user browser 122 receives a manifest file from the CDN providerserver(s) 112. If, at step 524, HLS streaming is requested, then at step528 the browser is redirected to the custodian HLS server 110. Then, atstep 530, the end user browser 122 downloads a manifest file from thecustodian HLS server 110. It will be appreciated that other streamingformats, such as MPEG-Dash, may either follow the same process as HLSstreaming, or be streamed via the CDN provider server(s) 112.

Once the end user browser 122 has downloaded a manifest file, whetherfrom the CDN provider server(s) 112 or the custodian HLS server 110, theprocess progresses to step 531. At step 531, the end user browser 122downloads a decryption key for use in decrypting segment files. At step532, the end user browser 122 downloads the next segment file availablevia links provided in the downloaded manifest file. At step 534, the enduser browser 122 decrypts the downloaded segment file using thedownloaded decryption key. At step 536, the content presentationinterface loaded in the end user browser 122 plays the downloaded anddecrypted segment. At step 538, the end user browser deletes thedownloaded segment file. At step 540, it is determined whether thesegment file downloaded in step 532 and deleted in step 538 was the lastsegment linked in the manifest file. If it was not the last segment, theprocess loops back to step 532 to download the next segment file. If, atstep 540, it is determined that the segment downloaded in step 532 anddeleted in step 538 was the final segment linked in the manifest file,the process moves to step 542 where the manifest file and the decryptionkey are deleted. It will be appreciated by one skilled in the art thatone decryption key may be downloaded for decrypting multiple sourcecontent, rather than downloading a new key for each source content. Forexample, one decryption key may be downloaded for an entire playlist ofcontent, to be used in decrypting each segment associated with each itemof content in the playlist.

At step 544 it is determined whether additional content is to be played.If not, the process ends at step 546. If there is additional content tobe played, the process loops back to step 518 to send the stream requestto the custodian server 104. Additional content may be played for anumber of reasons. In some embodiments, the end user 120 may also decideto replay or rewind the content currently being played, such as bypressing a “back” button or by dragging a progress bar back to thebeginning of the bar, which would result in needing to request thestream again as the segments already played would likely already bedeleted form the end user's machine. In other embodiments, a replay orrewind capability may not be present, depending on how the custodian 103and the customer 116 prefer the content to be streamed. Additionalcontent may also play if the content presentation interface implements aplaylist. In that case, the content presentation interface may moveforward to the next piece of content automatically, or the end user 120may choose to move forward in the playlist manually.

Referring now to FIGS. 6A-6B, there is illustrated a diagrammaticrepresentation of one embodiment of a HLS streaming process 600. The HLSstreaming process 600 includes a content server 602 and an end userdevice 604. As shown in FIG. 6A, the server may have any number ofindividual items of content stored and already segmented. For instance,there is shown in FIG. 6A, a first content (“A”) 606. First content(“A”) 606, as shown, may already have an associated manifest file(“AM.M3U8”) 608. For HLS streaming, manifest files typically have the.M3U8 file extension. Thus, in FIG. 6A the manifest file (“AM.M3U8”) 608is shown as being labeled “AM.M3U8”. The first content file (“A”) 606may also already be segmented, with the segments already stored on thecontent server. As shown in FIG. 6A, the first content file (“A”) isshown to have any number of segments, with a first segment file(“AS1.ts”) 610, a second segment file (“AS2.ts”) 612, and a last segmentfile (“ASn.ts”) 614, each segment file being already encrypted. It willbe appreciated that the “n” in the last segment file depicts any number,whichever number would in actuality be the last segment of the firstcontent file (“A”) 606. It will also be appreciated by one skilled inthe art that each segment would be divided into segments of equalplayback length, with the last segment constituting the remainder of thecontent, however long that may be. The length of each segment may varybased on the content provider 602's preference, but, for theillustrative embodiment, the segment files are divided into 10 secondseach. For example, a song that is 65 seconds in length would be dividedinto seven segments. The first six segments would be 10 seconds long,while the seventh and last segment would be 5 seconds long.

Additional content would also be stored on the content server 602. Asshown in FIG. 6A, there is a second content file (“B”) 616, also havinga manifest file (“BM.M3U8”) 618, a first segment file (“BS1.ts”) 620, asecond segment file (“BS2.ts”) 622, and a last segment file (“BSn.ts”)624, each segment file being already encrypted. There is also shown afinal content file (“Z”) 626. It will be appreciated that any number ofcontent files may be stored on the content server 602. The final contentfile (“Z”) 626 also has a manifest file (“ZM.M3U8”) 628, a first segmentfile (“ZS1.ts”) 630, a second segment file (“ZS2.ts”) 632, and a lastsegment file (“ZSn.ts”) 634, each segment file being already encrypted.

When the end user device 604 requests the streaming process to being, asdescribed hereinabove, a download stream 636 is initiated between theend user device 604 and the content server 602. Typically, each item ofcontent would be requested one at a time as the content presentationinterface needs require. Thus, the end user device 604 sends a request638 to the content server 602. The download stream 636 downloads themanifest file (“AM.M3U8”) 608 to a memory 640 of the end user device604. As described hereinabove, a manifest file contains links to eachcontent segment and a link to a decryption key to decrypt each contentsegment in order for the segment to be played. It will be appreciated byone skilled in the art that there may be one decryption key for allsegments of the item of content, or even one decryption key for allcontent in a playlist. Once the manifest file (“AM.M3U8”) 608 is loadedinto the memory 640, an associated decryption key, as well as the firstsegment file (“AS1.ts”) 610, the second segment file (“AS2.ts”) 612, andall remaining segment files up to the last segment file (“ASn.ts”) 614,are downloaded to the memory 640. It will be appreciated by one skilledin the art that each segment file may be loaded into the memory 640 atvariable rates, such that many segments may be queued up in the memory640 at once, downloaded and played one at a time, or any variationthereof, dependent on the speed of the connection between the contentserver 602 and the end user device 604, as well as other factors.Further, additional content in the playlist may be downloaded, orbuffered, into the memory 640, such as the second content file (“B”) 616to the third content filed (“Z”) 626. Buffering of additional content,including the manifest files, decryption keys, and file segmentsassociated with the additional content, will vary in degree depending onthe available bandwidth. Such buffering of additional content in theplaylist allows for uninterrupted and continuous playback of theplaylist.

As the segments are successfully downloaded, the segments are loadedinto the content presentation interface for playback through the enduser device 602. Each segment is decrypted only when it is needed forplayback. Thus, the first segment file (“AS1.ts”) 610 is decrypted usingthe associated decryption key 641 that was downloaded at the beginningof the stream, and playback begins. A playback timeline 644 shows thatthe first segment file (“AS1.ts”) 610 is played as the first 10 secondsof the content. Then, as playback of the first segment file (“AS1.ts”)610 is completed, the first segment file (“AS1.ts”) 610 is deleted fromthe memory 640 and the second segment file (“AS2.ts”) 612 is decryptedusing the associated decryption key 641 and loaded from the memory 640into the content presentation interface to continue playback. It will beappreciated that these steps preferably happen quickly so that the enduser does not experience any delay between the playback of the firstsegment file (“AS1.ts”) 610 and the second segment file (“AS2.ts”) 612.This process continues for the rest of the segment files, each segmentbeing decrypted, played, and deleted from the memory 640.

When the last segment file (“ASn.ts”) 614 needs to be played, since eachpreceding segment file was 10 seconds in length, in the illustrativeembodiment, the last segment file (“ASn.ts”) 614 would begin playing ata time denoted in FIG. 6A as 10(n-1)_(s). For example, if there were 4segments total, the last segment file (“ASn.ts”) 614 would begin playingat 10(4-1)_(s), or 30 seconds, into the playback of the item of content.The last segment file (“ASn.ts”) 614 would complete playback at a timedenoted as (10(n-1))+x_(s), where x is the length of the last segmentfile (“ASn.ts”) 614 in seconds. Thus, if the length of the last segmentfile (“ASn.ts”) 614 is 5 seconds, and there are again 4 segments total,playback of the first content (“A”) 606 would end at (10(4-1))+5_(s), or35 seconds, into the playback of the item of content. Once playback ofthe last segment file (“ASn.ts”) 614 is complete, the last segment file(“ASn.ts”) 614, the manifest file (“AM.M3U8”) 608, and the decryptionkey 641 are deleted from the memory 640. It will be appreciated that thedecryption key may not be deleted in embodiments where there is onedecryption key for an entire playlist of content. In that case, thedecryption key would not be deleted until the playlist finishesplayback, or based on some other criteria, such as time since playstopped.

It will be appreciated by one skilled in the art that, in someembodiments, if the end user manually, via the content presentationinterface, moves back to an earlier point in the content being playedback, previous segments would be downloaded again for the appropriatepoint in the content the end user manually moved to in the content, soas to begin playback from that point again. If the end user manuallyrestarted playback of the first content (“A”) 606, or if the contentpresentation interface was set to automatically replay the first content(“A”) 606, after playback of the first content (“A”) 606 was complete,the request 638 would be resent to the content server 602 to begin theprocess of playing the first content (“A”) 606 again. Such a method ofreplaying content or moving to a previous portion of content currentlybeing played may not be present in certain embodiments, depending on howthe content is chosen to be streamed. It may be desired that the enduser not be allowed to replay or rewind content, in which case thestreaming of content would simply continue in a predetermined order.

Still referring to FIGS. 6A-6B, the content presentation interface maybe set up to provide for playback of a playlist 646. Thus, afterplayback of the first content (“A”) 606 has completed, the contentpresentation interface may move forward to the next item of content inthe playlist 646, or the end user may manually move forward to the nextitem of content, such as via a forward button on the contentpresentation interface. It will be understood that, as describedhereinabove and in previous figures, there may be a request to thecustodian server 104 that takes place before the request 638 to thecontent server 602 in order to check access tokens, streaming formatcompatibility, or other factors. The stream of the second content (“B”)616 follows the same process described hereinabove regarding thestreaming and playback of the first content (“A”) 606. Thus, themanifest file (“BM.M3U8”) 618 is downloaded, followed by a decryptionkey 642, the first segment file (“BS1.ts”) 620, the second segment file(“BS2.ts”) 622, and the last segment file (“BSn.ts”) 624. These itemsmay have already been downloaded during playback of the first content(“A”) 606. There is shown a playback timeline 650 depicting the playbackof the second content (“B”) 616, in the same manner as the playbacktimeline 644.

After playback of the second content (“B”) 616 is complete, the processwould perform the same steps for all remaining items of content in theplaylist 646, utilizing new decryption keys. The final decryption key643 is shown in FIG. 6B. After a final request 638 is sent from the enduser device 604 to the content server 602, and after playback of thefinal content (“Z”) 626 is complete, as depicted by a playback timeline654, the process may end. If bandwidth allows, the items downloaded inorder to stream the final content (“Z”) 626 may already be buffered inthe memory 640 before playback of the previous content was complete.However, it will be appreciated by one skilled in the art that the enduser may, in some embodiments, via the content presentation interface,loop back to previous items of content, if desired. The contentpresentation interface may also perform a loop back to the beginning ofthe playlist 646 automatically. Such functionality allowing the end userto loop back to previous items of content, or the content presentationinterface doing such automatically, may not be a feature allowed incertain embodiments, depending on how content is desired to be streamed.

It will be appreciated by one skilled in the art that, in someembodiments, the buffering described in regard to FIGS. 6A and 6B maynot be a sequential buffering of all content in the playlist. Forinstance, some playlists may not necessarily play in sequential order,either by design or because of user input. For example, there may be areplay feature that allows the user to replay a song the user justlistened to. In that case, a buffering strategy may be desired thatallows for the content most recently played to remain in memory, so thatit can be replayed without needing to download the content again. Thecurrent item of content would be deleted from memory at a later time,such as after the next item of content has been played, rather than thecurrent item of content being immediately deleted after it is played. Inanother example, the user may be allowed to choose from a list ofcontent, with the user selecting a new item of content after each itemis played. In this case, a portion of each item of content may bebuffered, so that, regardless of which item of content the user selects,continuous play may be achieved. The selected item of content wouldimmediately begin playing the portion already buffered, and would beginbuffering the remaining portion of the item of content needed tocomplete playback. Other buffering strategies may be utilized, dependingon the nature of how content is desired to be consumed by the user.

Since HLS was developed with video streaming in mind, and under theassumption that video would be consumed one video at a time, HLS did notoriginally conform to playlist playback. Therefore, HLS does not providefor playlist functionality. Thus, the invention of the presentdisclosure provides for the content presentation interface to createplaylist information, keep track of playlist content, data, and accesstokens, and provide information concerning the playlist at the contentpresentation interface, such as the location in the playlist, the timeleft in each item of content, and other playlist location indicators.The manifest file contains information concerning each segment file,such as the length, in seconds, of each segment file. This allows thecontent presentation interface to add the length of each segment filetogether to display the length of the entire item of content to the enduser. The content presentation interface also can determine and display,using the manifest file, the current elapsed time, in seconds, of thecontent currently being played. This can be accomplished by determiningwhich segment is being played, and many seconds into that segment hasbeen played. For example, if each segment is 10 seconds and 5 secondshave elapsed into the second segment, the content presentation interfacedetermines and displays that the current item of content is at the 15second mark. It will be understood that the streaming process shown inFIGS. 6A-6B may be applied to other streaming formats, such as Flash,MPEG-Dash, or other streaming formats.

HTTP Live Streaming, given that it is based on HTTP protocol, is lesslikely to be disallowed by routers, Network Address Translation (NAT),or firewall settings. No ports that are commonly closed by default needto be opened. Content is therefore more likely to get through to theclient in more locations and without special settings. HTTP is alsosupported by more CDNs, a factor that can affect cost in largedistribution models. In general, more available hardware and softwareworks unmodified and as intended with HTTP than with RTSP or RTMP.Expertise in customizing HTTP content delivery using tools such asHypertext Preprocessor (PHP) is also more widespread. Additionally, forlarge-scale events, HTTP natively and easily supports mirroring and edgecaching, providing for massive-scale expansion when needed for thelargest events. RTSP and RTMP, protocols for Flash streaming, can alsobe cached, but HTTP does so natively and without the need forproprietary or custom configurations.

It should be understood that the drawings and detailed descriptionherein are to be regarded in an illustrative rather than a restrictivemanner, and are not intended to be limiting to the particular forms andexamples disclosed. On the contrary, included are any furthermodifications, changes, rearrangements, substitutions, alternatives,design choices, and embodiments apparent to those of ordinary skill inthe art, without departing from the spirit and scope hereof, as definedby the following claims. Thus, it is intended that the following claimsbe interpreted to embrace all such further modifications, changes,rearrangements, substitutions, alternatives, design choices, andembodiments.

What is claimed is:
 1. A system for content streaming with featuredetection, comprising: a content server disposed on a location on anetwork, the content server including content to be streamed; and awebpage having a content presentation interface, the contentpresentation interface providing: functionality to facilitate streamingof content to a web browser from the content server; feature detectionto determine a streaming format compatibility criteria of the webbrowser to determine if the web browser is HTTP Live Streamingcompatible, and, if so: a) the content presentation interface determinesa content selection from a list within the webpage of one or morecontent selections, each content selection including an identificationof content, a location of the content server, and an access token; b)the content presentation interface sends a HTTP Live Streaming requestof the content selection to the content server; c) the content serverreceives the request and begins a stream for playback via the webpage,wherein the content server divides the content into a plurality ofsegment files, encrypts the plurality of segment files, sends a manifestfile containing links to the plurality of segment files and to adecryption key associated with the plurality of segment files, and sendsthe plurality of segment files and the decryption key, for decryption ofeach of the plurality of segment files, as they are requested via thelinks in the manifest file; and d) steps a), b), and c) are repeatedwhile playback is performed until the last content selection is selectedand streamed, in order to buffer additional content to allow forcontinuous playback of the list of one or more content selections.